In recent years, VoIP telecommunication (e.g., a telephone call over the Internet) or multi-media telecommunication using ITU-T Recommendation H.323, or SIP (Session Initiation Protocol) based on IETF RFC 2543, has been continuously spreading widely. Some terminal devices and network devices (e.g., gateway devices) used in such a telecommunications system are implemented with various coding standards. For instance, a device may be furnished with coding standards of 8 Kbps (G.729), 16 Kbps (G.728), and 32 Kbps (G.726). By implementing multiple coding standards in a terminal device or a network device, the optimum coding standard can be selected among them, taking into account, for example, the use, the purpose, the speech quality, and the transmission capacity of the communication channel.
However, since there is generally no compatibility between different types of coding-standards, the coding standard used in the receiving side terminal and that used in the transmitting side terminal have to match with each other. Currently, ITU-T Recommendation H.245 and SDP (Session Description Protocol) based on IETF RFC 2327 define procedures for choosing the same coding standard on the transmitting side and the receiving side. These protocols include a negotiation protocol for selecting a coding standard at the beginning of or during the voice communication. Explanation is made below of such a conventional negotiation procedure carried out on the receiving side, using an example of SDP based on IETF RFC 2327.
First, a terminal on the transmission side describes available coding standards (definitions of the media used for voice communication) and the associated parameters, as well as the addresses of the caller and the callee, with SDP in an INVITE message of SIP, and transmits the INVITE message. This INVITE message contains information about multiple coding standards described with SDP. The terminal on the receiving side receives the SDP, and transmits data using an available coding standard selected from the multiple coding standards described with SDP. In this manner, voice communication is started between the transmission side and the receiving side, using the selected coding standard.
There are some coding standards that define various options. In this case, a determination has to be made during the negotiation whether to use these options, in order to select an appropriate coding standard. For instance, it is known that AMR (adaptive multi-rate) speech coding standard defined by ETSI (European Telecommunication Standards Institute)/3GPP (3rd generation partnership project) includes eight (8) coding modes. These coding modes can be selected and changed dynamically according to the communication environment. It is not necessary to use all of the eight coding modes, and voice communication is possible using a part of them. The transmission rates of the eight coding modes of the AMR speech coding standard are listed below.                Coding Mode 1: 12.2 Kbit/s        Coding Mode 2: 10.2 Kbit/s        Coding Mode 3: 7.95 Kbit/s        Coding Mode 4: 7.40 Kbit/s        Coding Mode 5: 6.70 Kbit/s        Coding Mode 6: 5.90 Kbit/s        Coding Mode 7: 5.15 Kbit/s        Coding Mode 8: 4.75 Kbit/s        
One example of a mobile communication system using the AMR speech coding standard is GSM (global system for mobile communication) standardized in Europe. In GSM, the maximum number of modes available in voice communication is limited by various factors. For example, the maximum number of available modes is limited to four (4) due to the conditions of the network resources and other factors. Consequently, a combination of modes used in voice communication has to be determined. In addition, when conducting telecommunications between terminals (i.e., mobile terminals in this context), the same combination of modes has to be used in both directions. For these reasons, coding modes have to be determined taking these restrictive conditions into account in GSM. However, the above-described negotiation procedure based on SDP has some problems, which are explained below using FIG. 1 and FIG. 2.
FIG. 1 and FIG. 2 illustrate the case in which the coding modes supported by the transmitting terminal and the receiving terminal differ from those actually available at the time of telecommunicating. In tables shown in FIG. 1 and FIG. 2, LSCS (local supported codec set) and DSCS (distant supported codec set) are the coding modes of AMR available at terminal 1 (e.g., the caller's terminal) and terminal 2 (e.g., the callee's terminal), respectively. LACS (local active codec set) and DACS (distant active codec set) make a pair of mode sets having been actually used at terminal 1 and terminal 2 prior to the negotiation. In this example, it is presumed that terminal 1 calls terminal 2.
In FIG. 1, terminal 1 describes LSCS using SDP in an INVITE message, and transmits this message to terminal 2. The LSCS indicates that six modes (coding modes 0 through 5) are supported at terminal 1. Upon receiving LSCS, terminal 2 selects the coding modes that are common between the six modes transmitted from terminal 1 and five coding modes (coding modes 0-2, 4, and 7) supported at terminal 2 itself. Then, terminal 2 transmits the common coding modes DACS to terminal 1. However, the coding mode set LACS that is actually available at terminal 1 at this moment is limited to coding mode 0 and mode 4, as indicated in FIG. 1. In this case, the terminal 1 cannot receive the response in coding mode 1 or 2. Thus, if the coding modes supported at terminal 1 are limited due to some restrictive factors, then terminal 1 cannot receive messages if they are encoded with a coding standard other than the actually available LACSs. In this case, voice communication may not be conducted.
FIG. 2 illustrates another example. In this example, terminal 1 describes LACS using SDP in the INVITE message and transmits the message to terminal 2. The terminal 2 is capable of communicating with terminal 1 using common coding modes (modes 0, 1, 2, and 4 in this example, which are in common between LSCS and DSCS). However, terminal 1, which first generates and transmits LACS in this example, may select and transmit modes 3 or 5 as the LACS to terminal 2. Then, terminal 2 cannot receive the data encoded by mode 3 or 5, in spite of the face that there are common coding mode existing between terminal 1 and terminal 2. This case also prevents voice communication between end terminals.
These problems also occur using the H.245 standard.